Software Component Template

原文：AUTOSAR_CP_TPS_SoftwareComponentTemplate

总览

Software Component Template（SWCT）是 AUTOSAR 规范体系中的核心模板规范之一，用于定义软件组件（SWC）的建模方式、结构组成及其交互关系，为软件组件的设计与集成提供统一的描述规则。

本文档定义了关于 SWCT 的相关标准，规定了软件组件 Arxml 的编写格式，服务于 ECU Extract、System Description、RTE Generator。主要包括：

对于 SwComponentType 的描述。本文中，SWCT 被认为是一个可以通过 PortPrototype 定义的实体（Entity），即在 SWCT 的语义体系中，SwComponentType 的“外部可见行为”完全由 PortPrototype 定义。
对于 CompositionSwComponentType 的描述，即由相互具有链接关系的 SWC 组件组成的子系统。CompositionSwComponentType 本身不实现行为。SWC 可以通过层级结构进行定义，这种定义由更多的 SWC 构成。即树形结构（建模层级结构）：

SwComponent_Father
	SwComponent_Child_1
	SwComponent_Child_2
	...

对在BSW Module Description Template 中提到的 AtomicSwComponentType 的描述，其可以作为 SW 的一部分被映射到 ECU 中。如下图所示。

绿色框体表示该部分在 SWCT 中得到了完整描述，蓝色框体表示该部分仅有接口（Interface）得到了完整描述。

概念阐释

本部分对于在 SWC 中可能出现的概念进行了阐释。现举几例。

Runtime and Data Consistency Aspects

该部分提供了关于实现 RTE 与 Runnable Entity 之间高效通信的方案。

可以通过共享内存实现。但是其只能被集中在特定的处理单元上（由于需要共享内存）。
使用全局变量建立内部通信。由于通信的目的是为了建立 Data Flow，所以这样就会产生定义：状态消息（state-messages）。

共享内存实现有一个很严重的问题：Runnable Entity 之间的数据一致性（Data Consistency）。由于 Runnable Entity 相当于 RTOS 中的任务（Tasks），则根据任务的抢占规则，其会被同一个 AtomicSwComponentType 的其他 Runnable Entity 抢占。这样，数据可能会在运行期间被篡改。

以下是一系列解决内存一致性的方法：

通过信号量（Semaphore）实现互斥锁。
通过禁用中断（Interrupt）。
通过优先级封顶（Celling）策略。即通过设定优先级最高的策略，避免被抢占。
通过变量复制。即创建副本从而避免被改变，如图所示。

在运行时内存一致性（Data Consistency at Runtime）上，也有一系列方案被提及。

比如复制进程（Copy routine）必须确保在复制过程中不能被其他进程打断以保证连续的复制操作（虽然这个复制进程运行时间是相对短暂的）。

其还提到了一系列更优的策略（optimization criteria）：比如将复制任务（Copy Task）作为最高优先级，以保证绝对的安全。

同时，为了保证应用代码不受任何代码生成过程的影响，对这些复制变量的访问会通过宏定义（MICRO) 进行保护，宏定义由代码生成器进行解析。这些宏定义的存在支持了源代码（source Code）层级的复用。只有当调度场景（如优先级）保持一致时，才支持目标代码（object Code）层级的复用。AtomicSwComponentType 必须将所有并发访问的变量对外公开。

Variant Handling in the SWCT

SWCT 允许部分模型元素存在变体（Variant）（及存在与否、取值等），具体列表在附录J。这些变体即影响 Arxml，也影响 RTE 行为。

这是 AUTOSAR Methodology 的核心之一：模型不等价于最终系统。模型可以先定义其存在，之后通过 Variant 裁剪，在构建阶段决定是否生效。

比如：SwConnector 的 PostBuild 变体 [TPS_SWCT_01040]

SwConnector 的存在与否取决于 PostBuild 条件（如 Precompile/ Post-build）。SwConnector 会连接在某个 PortPrototype 上，如果其存在，则 RTE 通信行为正常，端口正确连接；若不存在，则 RTE API 也依然存在。 API 不会因为 SwConnector 不存在就消失，即其仍然会在 RTE 生成阶段被保留。

比如以下 Arxml：

xml

<SW-CONNECTOR>
  <SHORT-NAME>C_Speed</SHORT-NAME>
  <VARIATION-POINT>
    <POST-BUILD-CONDITION>
      <BOOLEAN-VALUE>true</BOOLEAN-VALUE>
    </POST-BUILD-CONDITION>
  </VARIATION-POINT>

  <PROVIDER-IREF>
    <CONTEXT-COMPONENT-REF DEST="APPLICATION-SOFTWARE-COMPONENT-TYPE">
      /SWC/SWC_A
    </CONTEXT-COMPONENT-REF>
    <TARGET-P-PORT-REF DEST="P-PORT-PROTOTYPE">
      /SWC/SWC_A/P_Speed
    </TARGET-P-PORT-REF>
  </PROVIDER-IREF>

  <REQUIRER-IREF>
    <CONTEXT-COMPONENT-REF DEST="APPLICATION-SOFTWARE-COMPONENT-TYPE">
      /SWC/SWC_B
    </CONTEXT-COMPONENT-REF>
    <TARGET-R-PORT-REF DEST="R-PORT-PROTOTYPE">
      /SWC/SWC_B/R_Speed
    </TARGET-R-PORT-REF>
  </REQUIRER-IREF>
</SW-CONNECTOR>

其生成的 Rte API：

Std_ReturnType Rte_Read_SWC_B_R_Speed(uint16* data);
Std_ReturnType Rte_Write_SWC_A_P_Speed(uint16 data);

是完全相同的。

就算 PostBuild Condition 为 False，也是会生成这两个 Rte API，只不过不发生动作。

P/R Port Prototype

P/R Port Prototype 的引入是为了对于同一块数据的读写需求。

在 AUTOSAR Classic Platform 中，端口（PortPrototype）是软件组件之间进行数据交换的核心建模元素。传统模型中，端口被严格区分为：

PPortPrototype（Provide Port）：仅具备 Write / Provide 语义，用于“生产”数据；
RPortPrototype（Require Port）：仅具备 Read / Consume 语义，用于“消费”数据。

这种严格区分在“单向数据流”场景下是合理的，但在大量实际工程场景中，会出现同一块数据需要被反复读写的情况。如果仍然强制使用 RPort + PPort 的组合，就会引入一系列问题。

基于此，AUTOSAR 引入了 PRPortPrototype。其绑定了同一份数据元素，在 Runnable Entity 中既可以调用 Write API，也可以调用 Read API。

举例分析

NvM / NvBlock 场景下，需要对同一块内存进行读写操作。当没有 PRPort 时，其必须定义一个 P-Port，一个 R-Port。这两个端口指向同一个数据块，其模型复杂，一致性约束多。作为自然语义，我们引入 PR Port，对外暴露相同的 P/R 端口，内部映射到同一个 RAM Block。

Software Components 概述

Autosar概念的核心目标之一，就是支持应用软件层面的复用性。换言之：开发者应能通过复用现有构件来构建更多模型元素，而非被迫从零开始逐个创建建模细节。

这种设计理念的必然结果就是类型原型模式。该概念允许构建任意复杂度的软件组件层级结构，但需注意：层级结构的构建本身不会影响系统运行时的行为，实际运行逻辑完全由各个软件组件自主决定。

软件组件是基于所谓的虚拟功能总线（VFB）开发的，这是一种不直接依赖 ECU 和通信总线的抽象通信通道。 VFB 本身并不提供表达软件组件层级结构的手段。当然， VFB 的使用对软件组件的设计产生了进一步影响——这些组件不应直接调用操作系统或通信硬件。因此，软件组件往往要到开发流程的后期阶段才能部署到实际的ECU中。

AUTOSAR 的应用软件（Application Software）通过一些自包含（self-contained）的单元，即 AtomicSwComponentType 组成。这些 AtomicSwComponentType(s) 封装了其功能和行为的实现，仅向外部世界暴露明确定义的连接点（称为 PortPrototype(s) ），如图所示。

首先有所有 SWC 的抽象基类（abstract）：SwComponentType。其具有子类：

AtomicSwComponentType
CompositionSwComponentType
ParameterSwComponentType

其次有一系列属性：

consistencyNeeds - 用于进行一致性约束规则校验。
port - SWC 的通信端口，支持所有 R/P Port。核心属性之一。
portGroup 对 Port 的逻辑分组。
swcMappingConstraint - 对于 SWC 映射的相关约束，约束其到 ECU/OS/Core 的关系。
swComponentDocumentation - 对 SWC 附加的文档说明
unitGroup - 该 SWC 允许使用的单位集合（可选）

PortPrototype

SwcComponentType 的 PortPrototype 一般被用于链接 SwConnector，从而在 SwComponentPrototype(s) 中建立连接。

软件组件（Software Components）通过 PortPrototype 进行交互，且具有可替换性。即只要功能一致、端口一致，就可以互换。

PortPrototype 必须依赖 PortInterface，用以描述完整的通信细节。

分为 P-Port、R-Port 和 P/R-Port。允许的连接关系如下：

P - R
P - PR
PR - R
PR - PR

上图标明了 PortPrototype 的分层关系。即在 P/R/P-R Port 之上存在 Provided/Required 抽象，其共同属于 PortPrototype。

AtomicSwComponentType

Atomic SwComponentType 与常规 SwComponentType 的区别是其可以聚合 SwInternalBehavior。这使得 AtomicSwC 成为真正可执行语义的组件类型。

一个 AtomicSwComponentType 对应一个 ECU 上的执行实体。

上图为 SWCT 总览。在图中 AtomicSwComponentType 的子模块中：

ApplicationSwComponentType 是 AtomicSwComponentType 的特化类型，用于表示与硬件无关的应用软件。
ParameterSwComponentType 作为 SwComponentType 的特化类型，与 AtomicSwComponentType不同，它无法聚合 SwcInternalBehavior。
其他模块在文档后续章节有所介绍。

ParameterSwComponentType

ParameterSwComponentType 是参数/标定专用的软件组件类型，用于承载标定参数定义与映射，不是可执行组件。其不聚合 SwcInternalBehavior，即没有 Runnable等，而只聚合 P-Port。其只对外提供参数，不执行。

CompositionSwComponentType

这是在 SwComponentType 子类中的架构层容器，用于聚合已有的软件组件（SwComponentType）。其只做结构组织和层次抽象，不引入功能。即，只是逻辑结构的文件结构，而非可执行组件。

CompositionSwComponentType 不直接包含 SwComponentType，而是包含 SwComponentPrototype，其通过 type 指向某个 SwComponentType。这样，可以允许同一个 SwComponentType 具有不同的 SwComponentPrototype，实现不同的角色。

例如，可以通过指定 DoorControl 作为 SwComponentType，分化出 Left/Right DoorControl 两个 Prototype 角色。

CompositionSwComponentType 同样可以具有 PortPrototype，但是只能是 Delegation Port（委托端口）。其自身不实现通信，而是将内部组件端口暴露到外部。

Composition 内部通过 SwConnector 进行链接。以下是可能的 SwConnector 种类：

AssemblySwConnector：实现内部组件之间的链接，P - R
DelegationSwConnector：实现内部组件与外部端口之间的链接：P - DP
PassThroughSwConnector：转发外部端口，不与内部组件交互。

同一对 PortPrototype 只能有一个 SwConnector。ASWC 和 DSWC 都只能作用于当前的 CSWCT。

Software Components 详细描述

根据 AUTOSAR 标准 [AUTOSAR EXP Virtual Function Bus]，软件组件（SWC）间的主要通信模式为：

基于操作的 Client / Server
基于数据的 Sender / Receiver

这两者的性质和建模方式均有一定差异。

对于非 Service 类型的 PortInterfaces，其编码形式是固定的：

2C 补码
IEEE754 浮点
ISO-8859-1/2 or WINDOWS-1252 or UTF-8/16 or UCS-2

这些基础的数据可以被高效映射到 C 编码，保证 RTE 的可预测性和兼容性。

Service 类型的通信不受限制 [TPS_SWCT_01845]

Sender / Receiver 通信

Sender / Receiver 结构使用了一种发送 / 接收的数据结构，即 SenderReceiverInterface。其定义了有哪些数据以及数据的语义。通信依然通过 PortPrototype。

dataElement 表示独立的数据项。Sender / Receiver 通信模型的模块间使用 dataElement 表示数据传输。

PRPort 不允许队列语义（queued），因为 PRPort 为同时读写，队列语义会破坏 Data Consistency。

Sender / Receiver 通信只允许：

1 - N
N - 1 不允许：
N - M

该图描述了 SenderReceiverInterface 的连接关系。

InvalidationPolicy

数据失效机制允许 Sender 主动标记数据无效。其 handleInvalid 存在以下值：

dontInvalidate - 关闭失效
keep - RTE 错误由 Application Software 处理
replace - 用 initValue 替换
externalReplacement 用外部值替换

Meta-Data

元数据是一种仅有 SenderReceiverInterface 支持的类型。

用于传输非业务数据，比如：

CAN ID
J1939 Source Address
Timestamp
VLAN ID

其绑定到具体的 dataElement。

Client / Server 通信

Client / Server 通信的本质是 Client 调用 Server 的函数，支持同步和异步调用。

一个 Client 不能链接多个 Server，避免调用函数冲突。

同样的，该种通信模式也定义了接口： ClientServerInterface。其可以调用 Operation 或者可能的 ApplicationError。

ClientServerOperation 由多个 ArgumentDataPrototype 组成。参数的方向为：

in
out
inout

这很接近 C 函数签名 / 调用逻辑的定义。

Client / Server 提供了一系列错误处理：

Infrastructure Error - RTE / 通信故障
Application Error - 接口语义 / PortInterface 定义

External Trigger Event Communication

External Trigger Event 不能够传输数据，而是触发执行。在 Trigger Source 触发后，驱动连接的 Trigger sink 中的 Runnable Entity 执行。

TriggerInterface 是一种 PortInterface，用于声明 Trigger 集合，由 Source 端触发 Trigger，Sink 端接受并执行函数。

Trigger 是具体的触发事件，能够表达：

swImplPolicy：处理方式。
- STANDARD 触发即处理
- QUEUED 使用队列，用 FIFO 处理
triggerPeriod：触发周期

其还提供一种时间周期表示：MultidimensianalTime，用于表达时间/角度类周期。

TriggerInterface 和 Trigger 的表示关系如下：

Mode Communication

AUTOSAR 针对模式通信做了描述。模式通信主要有两种使用方式：

模式切换通知（Mode Switch）
- 该方式是从 Mode Manager 到各组件，用以使某个组件进入特定模式。其使用 ModeSwitchInterface，接口中只包含 ModeDeclarationGroupPrototype，用以定义某些模式。
模式切换请求（Mode Request）
- 该方式是从组件到 Mode Manager，即请求切换到某种模式。其使用 SenderReceiverInterface，通过数据通信请求模式。数据须为 AutosarDataType。

其中，ModeSwitchInterface 若在 CompositionSwComponent 中，CompositionSwComponentType 会自动继承内部 SWC 的模式需求，通过 DelegationSwConnector 对外暴露。

虽然 Mode Request 是数据通信，但语义上仍然需要对应 ModeDeclarationGroupPrototype。所以，模式请求的数据类型映射是必要的，即 ModeRequestTypeMap。

ModeRequestTypeMap 会映射到 ImplementationDataType，且其是一一对应关系。ModeRequestTypeMap 必须存在。

PortInterface Mapping and Data Scaling

在早期的 AUTOSAR 标准中，要求 PortInterface 需要严格匹配，但是语义一致形式不同的接口则无法连接，故引入 PortInterface Mapping 用以显式声明其对应和转化关系。其适用于[TPS_SWCT_01158]：

SHORT-NAME 不同，但语义一致
量纲/范围/分辨率不同
invalidationPolicy 不同
可以通过 AUTOSAR Data Transformer 做复杂变换的其他情形

Mapping 独立于 SwConnector，且优先级最高，即可以覆盖其他兼容性规则。一个 PortInterfaceMapping 可以映射两个 PortInterface，未映射的元素不会被链接。

Mapping of Sender Receiver Interface, Parameter Interface and Non-Volatile Data Interface Elements

使用类：VariableAndParameterInterfaceMapping 和 DataPrototypeMapping，映射不同接口中的 VariableDataPrototype 或者 ParameterDataPrototype。

Mapping of Client Server Interface Elements

使用类：ClientServerInterfaceMapping、ClientServerOperationMapping、ClientServerApplicationErrorMapping，映射两个 ClientServerInterface 中的 Operation、Arguments、ApplicationError。

Mapping of Mode Interface Elements

使用类：ModeInterfaceMapping、ModeDeclarationGroupPrototypeMapping、ModeDeclarationMappingSet / ModeDeclarationMapping 等，显式定义 ModeDeclaration 之间的对应关系。

Mapping of Trigger Interface Elements

使用类：TriggerInterfaceMapping、TriggerMapping，映射不同 TriggerInterface 中的 Trigger。

Mapping of Elements of a composite Data Type

使用类：SubElementMapping、SubElementRef，在 DataInterface 场景下进行元素映射。

AUTOSAR 规定，可以通过以下 RTE 支持的类型进行数据转换：

IDENTICAL 不转换
LINEAR 线性
SCALE_LINEAR_AND_TEXTTABLE 单个线性区间
TEXTTABLE 枚举/表映射
BITFIELD_TEXTTABLE 位域枚举映射
RAT_FUNC

Port Annotation

Port Annotation 不影响接口和调用签名，也不影响 RTE 生成，用于补充语义和工程信息，用于开发者理解和校验。基于 GeneralAnnotation 类。

Communication Specification （ComSpec）

PortInterface 只定义了结构，但是没有定义通信行为。ComSpec 用于定义通信属性：可靠性、初始值、队列状态等。

ComSpec 绑定在 PortPrototype 上，而不是 PortInterface 上。

ComSpec 具有 PPortComSpec、RPortComSpec、PRPortComSpec 三种。

下面以 Sender / Receiver 通信模型为例，说明 ComSpec 的主要内容。

对于 RPortPrototype，其定义的类名为 ReceiverComSpec。对于 PPortPrototype，其定义的类名为 SenderComSpec。

其定义了 QUEUED / NON-QUEUED 两种队列模式。对于 QUEUED，其需要使用 QueuedSenderComSpec / QueuedReceiverComSpec。反之同理。

对于 NonqueuedReceiverComSpec，定义了以下属性：

initValue
aliveTimeout
handleTimeoutType
enableUpdate
handleNeverReceived
filter
...

Port Groups within Component Types

End to End Protection

Partial Networking

Formal Definition of implicit Communication Behavior

其余内容参见标准文档。

Data Description

AUTOSAR 为数据建立了三层抽象：

Application Data Level

应用数据层，为 ApplicationSwComponentType 提供语义抽象，其用于 SWC 之间的数据语义一致。

Implementation Data Level

实现数据层，面向代码抽象，提供给 RTE、BSW 接口、数值库使用。其关注于 C 语言层面的类型抽象（typedef）以及指针、union、数组等内存相关结构，作为 RTE 生成的直接输入。依然是模型抽象，并非 CPU 表现。即：该数据在 C 中如何表示。

Base Type Level

该类型平台相关，用于构建 ImplementationDataType。即数据在硬件上的存储方式。

举例

对于车辆速度 VehicleSpeed：

在Application Data Level，其名称为 VehicleSpeed，对于 SWC 来说只具有语义含义：Vehicle Speed。

在 Implementation Data Level，其在 C 中的实现类型为 uint16，体现为：

typedef uint16 VehicleSpeed_ImpType;

这是一个数值型接口类型，供 RTE、BSW 使用。

在 Base Type Level 中，其类型为 uint16，即：

typedef uint16_t uint16;

综合起来即：

/* 平台层（Base Type） */
typedef uint16_t uint16;

/* RTE 生成（Implementation Data） */
typedef uint16 VehicleSpeedType;

/* SWC 使用 */
VehicleSpeedType speed;

Rte_Write_VehicleSpeed(speed);

文档提供了全面的关于信号/变量类型的描述，包括对于三层信号抽象模型各层变量类型的描述。例如：

对于 ApplicationDataType，其对其定义子类：

ApplicationRecordDataType
ApplicationArrayDataType

通过 Category 决定语义形态，并向其添加物理约束：DataConstr / PhysConstrs / lowerLimit / upperLimit，并进行语义映射、单位和初始值等。

Data Catagories 用于约束可配置的数据属性，即定义为不同的数据类型用以区分。

同时，文档还提供了关于数据原型（Data Prototype）的说明。

Data Prototype 是数据类型在某个上下文中的“角色实例”。其通过 isOfType 指向某个 AutosarDataType，并被其他模型元素整合。即，定义该数据在某个场景的具体用途。具体子类和上下文关系如图。

正如前文所述，数据类型定义及原型可附加多种属性与关联。这些特性由元类 SwDataDefProps 定义，该类全面涵盖特定数据对象在不同维度的属性。

通常，SwDataDefProps 中定义的属性可适用于软件组件模板（SWCT）及基础软件模块描述模板（BSWMDT）中声明的所有数据类型，例如组件本地数据、通信数据、测量数据以及校准数据。但属性约束会根据数据用途而有所不同。

即，对于在 SWCT 和 BSWMDT 中出现的数据对象，其所有关键属性被集中在 SwDataDefProps 中。

下表表示了 SwDataDefProps 中的属性，图片仅举几例。

标准文件提到，初始值（Initial Value）是必要的，因为VariableDataPrototype / ParameterDataPrototype 可能在未被软件显式赋值前就被访问。为了避免未定义的行为（UB），AUTOSAR 标准允许定义初始值。

AUTOSAR 将初始值赋值定义了不同的层级：

DataPrototype 层
ComSpec 层
CalibrationParameterValue 层

三层之间存在下层覆盖上层的关系。

Compatibility

在链接不同的 SwComponentType 前，有必要验证其形式兼容性。从而避免语义不一致的问题。兼容性的判断方法一般为自底向上（bottom-up），即先定义 AutosarDataType 的兼容规则，然后定义各类 PortInterface 的规则，同时考虑映射关系。

文档给出了以下情况的兼容性规则：

Data Types
Variable Data Prototypes and Parameter Data Prototypes
Sender / Receiver，Parameter interfaces and Non Volatile Data Interfaces
Mode Switch Interfaces
Mode Declaration Group Prototypes
Mode Declaration Groups
Argument Prototypes
Application Errors
Client / Server Operations
Client Server Interfaces
Trigger Interfaces
Provided Port Prototype
Case of a Flat ECU Extract

Internal Behavior

这部分对 BSW Module Description Template 中描述的 BSWMDT Three Layer Approach 三层架构中的中间层 BswInternalBehavior(SwcInternalBehavior) 做了更为详细的说明，即形式化描述 AtomicSwComponentType 的内部行为，说明了组件内部的运行逻辑，支持了接口先行、行为后补的 AUTOSAR Methodology。

Implementation

这部分对 BSW Module Description Template 中描述的 BSWMDT Three Layer Approach 三层架构中的底层 BswImplementation(SwcImplementation) 做了更为详细的说明。这部分 SWCT 和 BSWMDT 是模板共享的。SwcImplementation 是 Implementation 的 SWC 特化，留在了 SWCT 文档中。

Mode Management

SWCT 为 Mode Management 提供了通用的建模机制，而不是具体的模式。具体的模式通常在 BSW 或者 Application SWC 中实现。

Mode Manager 与 Mode User (Modules) 间通过 ModeSwitchInterface 通信，且只允许 1:1 或者 1:n 的形式，即一个 RPortPrototype(ModeSwitchInterface) 只能连接一个 SwConnector。

Mode Management 利用 ModeDeclarationGroup 描述可用状态集合，用 ModeSwitchInterface + RTEEvent 链接模式变化和 Runnable Entity 行为。

此处 Runnable Entity 用于发起模式切换

ECU Abstraction and Complex Drivers

该章节用于解决硬件资源（ECU Resource Template）与软件组件（SWCT）之间的对接问题，明确传感器/执行器到应用软件的完整信号链及其在 AUTOSAR 分层中的映射。

该章中定义了一系列信号链，用以链接硬件和软件。AUTOSAR 将物理量到软件数据的过程拆分为多个明确的阶段，并在软件架构中一一对应：

物理量（Physical Value），如：温度、速度、光强
传感器（Sensor），将物理信号转化为电信号
ECU Electronics ，对电信号进行处理
$\mu C$ 外设（ADC/DIO/PWM 等），将电信号转化为数字量
MCAL，将外设采样提供给上层软件
ECU Abstraction，反向补偿 ECU Electronics 的电气转换，转换为电气量
SensorActuator SWC，反向变换，将电气量转化为物理量的软件表示
Application SWC，通过 RTE 使用物理量

每一次硬件侧的物理/电气转换，在软件侧都有一层对应的反向抽象

正如图所示：

AUTOSAR 还提供了一种特殊的驱动：Complex Device Driver。

其定义了类 ComplexDeviceDriverSwComponentType，用以在某些需要严格实时性的场景允许受控地直接与硬件交互，不通过 ECU Abstraction 路径。同时，为非 AUTOSAR 控件提供功能封装。

可移植层

Software Component Template ​

总览 ​

概念阐释 ​

Runtime and Data Consistency Aspects ​

Variant Handling in the SWCT ​

P/R Port Prototype ​

举例分析 ​

Software Components 概述 ​

PortPrototype ​

AtomicSwComponentType ​

ParameterSwComponentType ​

CompositionSwComponentType ​

Software Components 详细描述 ​

Sender / Receiver 通信 ​

InvalidationPolicy ​

Meta-Data ​

Client / Server 通信 ​

External Trigger Event Communication ​

Mode Communication ​

PortInterface Mapping and Data Scaling ​

Mapping of Sender Receiver Interface, Parameter Interface and Non-Volatile Data Interface Elements ​

Mapping of Client Server Interface Elements ​

Mapping of Mode Interface Elements ​

Mapping of Trigger Interface Elements ​

Mapping of Elements of a composite Data Type ​

Port Annotation ​

Communication Specification （ComSpec） ​

Port Groups within Component Types ​

End to End Protection ​

Partial Networking ​

Formal Definition of implicit Communication Behavior ​

Data Description ​

Application Data Level ​

Implementation Data Level ​

Base Type Level ​

举例 ​

Compatibility ​

Internal Behavior ​

Implementation ​

Mode Management ​

ECU Abstraction and Complex Drivers ​

Services ​

Software Component Documentation ​

Service Dependencies and Service Use Cases ​

Rapid Prototyping Scenarios ​